1. Technical Field
The invention relates to electronic commerce in a computer environment. More particularly, the invention relates to the creation, organization, and resolution of rules modeling and governing the behavior of business transactions in a computer environment.
2. Description of the Prior Art
The problem in developing business applications is the nature of the “real-world.” Developers have constricted business applications into set patterns and have “normalized” data and methods where possible. The problem arises when the real world changes and the developer has to change the application program code.
The concept of “parameters” used by an application program to specifically direct the application program on how to process data was popularized in the early years of data processing. An example of one of these parameters is the “run date.” The run date parameter was used as a basis for calculating various other dates within the context of that one execution of that program. The run date could be used to calculate if payments were late or the expected ship date of a product.
The next logical step was to have a list of parameters passed to the program that controlled the programmatic behavior for the duration of the program execution. This list of parameters could include a variety of data, sometimes called switches, fields, toggles, indicators, etc. These parameters were constant for the entire duration of that program being executed, and were only changeable across multiple executions or batches of data. The parameters were fixed by design and required program changes to implement new behaviors.
The next major step was to include parametric fields into specific file formats. For example, a customer master record may have a taxability indicator using Yes (Y) or No (N). This indicator controls the application of sales tax based on the value of the field. The value could be selected by customer versus determined by batch execution of a program with a parameter and constant for all customers.
The industry then realized that data for customers and products may interact and produce different results. For example, a product record may have a taxability indicator (Y/N) that, when the product is not taxable, and the customer is taxable should result in no tax being paid. This is a simple and clear example of how specific instances of objects can interact.
However, the problem is that many objects may interact to define the correct answer and in ways that may not always be expected at the time a program is designed.
It would be advantageous to provide a business rules system that can create solution sets in reaction to the dynamic changes of the real-world business environment. It would further be advantageous to provide a business rules system that allows the user to easily create and maintain the rules describing and governing the system.